Mobile and fixed networks today generally employ a diverse set of networking gateway elements which can perform a variety of tasks including subscriber management, billing and charging, authentication, security (e.g., firewall, malware detection, etc.), tunnel management, session management, and mobility management, etc. Despite the wide range of gateway offerings they generally share a common architecture. Such architecture is commonly referred to as modular computing systems or blade servers.
Modular computing and communications systems, such as blade servers, are in widespread use in corporate data centers and telecommunications facilities around the world. A typical blade server can include a metal chassis, which can contain one or more slots, into which computing or communications processing blades can be inserted. Aside from common power, cooling, and management interfaces, blade servers typically contain one or more switch fabric cards that can provide inter-slot communications in the chassis using, for example, Ethernet or some other packet formats. External network communication are typically supported through network input-output (NIO) ports. A NIO port can either be integrated into a processing blade or on a separate module that is plugged into the rear of a given blade via a connector. It follows that network traffic enters and exits through these network ports and, if necessary, is routed to the appropriate blade by the system's switch fabric card(s). These components can be housed in a multi-slot chassis which can provide common power, cooling, system management, and control functions.
FIG. 1 illustrates a block diagram of a conventional modular computing and communication system 100. The system 100 can include ports 110 (e.g., P1, P2, . . . Pn), processing blades 120 (e.g., B1, B2, . . . Bn), and an inter-slot packet switch fabric 130. In system 100, network traffic can ingress into and egress from the ports 110. In some implementations, the processor blades 120 can be integrated with the ports 110 or be paired together. In some implementations, the processing blades 120 can be run individually as independent network elements or collectively as a pooled resource. The ports 110 can typically be configured in such a way that they can be assigned to specific processing blades 120. In operation, network traffic can be forwarded to a corresponding processing blade 120 for processing network traffic and providing further routing and other value-added services. Network traffic can also be forwarded across the processing blade 120 via the switch 130, depending on the traffic processing logic and routing decisions made at the processing blade 120. Traditional blade server systems such as the system 100 may provide rudimentary scalability through addition of processor blades 120 and ports 110. In such systems the processing blades 120 can typically be treated as standalone or as loosely coupled processing elements. However, these systems do not provide fine-grain control or scalability of computing or communications services.
FIG. 2 demonstrates a sample network traffic path in the conventional computing and communication system 100 in FIG. 1. In this example, network traffic ingresses at a port 110 (e.g., P1) and is usually bound to a specific processor blade 120 (e.g., B1) for, e.g., the management and routing of subscriber sessions. However, network traffic sometimes can be routed via the switch 130 to a different processing blade 120 (e.g., B2). In this situation, latency increases due to the multiple hops into and out of the system 100. Depending on the number of hops this latency can be significant and thus can result in degraded (suboptimal) performance.
FIG. 3 illustrates a block diagram of another conventional modular computing and communication system 300. The system 300 can include ports 310 (e.g., P1 . . . Pn), processing blades 320 (e.g., B1 . . . Bn), an inter-slot packet switch fabric 330, a standby port 340, and a standby processing blade (SPB) 350. The system 300 can provide some degree of service availability through, for example, the use of the SPB 350. The SPB 350 can provide the same functions as the processing blades 320 it backs up. In some implementations, the SPB 350 can maintain a global table/database of sessions of each active processing blade 320. The SPB 350 can back up as few as one processing blade 320, in which case this is known as 1:1 redundancy, or it can back up an arbitrary number (N) of processing blades 320, which is referred to as 1:N redundancy. When the failure of a processing blade 320 is detected, the SPB 350 can be switched from the standby mode to the active mode and can use its session database to re-establish sessions that were hosted on the failed processing blade 320. Depending on the implementations, the number of active sessions, and the complexity of the services being delivered, complete session recovery can take as much as several minutes. In addition, the need to maintain complete global knowledge of all active sessions imposes increased computational, memory, and intra-chassis communications requirements on the SPB 350, compared to the processing blades 320 it backs up. It naturally follows that the SPB 350 usually has a different hardware and software configuration from the active processing blades 320 and has scaling limits.